I will, once the input files are ready - while I expect - as discussed no bfb, but just similar results in the range of numerical precision to small discrepancies due to different conservative re-gridding methods that were previously and are now used for the input files.

But you can test that for the SAME input file (the already existing cmip-1850 files) this change should be bit for bit, or not?

Good idea, but I am afraid, not, since I was previously doing the remapping AFTER summing up NHx and NOy for the default model (for ndep) without the extended nitrogen cycle - so there could be also some small discrepancy (now confirmed through a check). What I currently do, is to check the new input files against the old input files - and look at the differences, when summing up NHx and NOy.

Ah, ok I see, thanks for the explanation.

@JorgSchwinger @jmaerz - it would be good to strategize how to move forwards with the ability to do the remapping in the nuopc cap using streams rather than mapping offline.

Hi @mvertens , not yet being familiar with the nuopc cap, I wonder, how it would e.g. deal with having to plug together different files, sum up their variables, potentially extend the files by one year, or pick only one specific year provided by a particular file. Just to name a few culprits that I stumbled upon when re-gridding the files recently. Of course, it would be very elegant to directly use the provided input4MIPs files for any of those tasks through the nuopc cap. @JorgSchwinger , you suggested some discussion points for a BLOM meeting in that respect. Maybe we can discuss this either in #376 or open a new issue for discussion on this?

Just to note: the script for re-gridding N-dep is almost there (year 2000 is missing and the extension by 1 year, if needed - which both should be straight forward to add + info, which 0.125 grid to use).

@jmaerz - by the "nuopc cap" I mean the code in $SRCROOT/components/blom/drivers/noupc.
One important point to note -

• nitrogen deposition is always sent from atm now (either CAM or DATM) - so BLOM should never have to read it when running with CMEPS. '
• Right now there is no code in the nuopc cap to receive ndep when hamocc is defined and I think that's a problem.
• When running with CAM - BLOM should not call do_ndep - since that data is obtained from CAM. This is particularly important since you want both CTSM and BLOM to receive the same ndep forcing in a coupled context.
• When running with DATM - it would be best if the NDEP stream came from DATM rather than an internal call. CTSM has moved in that direction. if BLOM calls do_ndep - it is overriding information obtained from the mediator. for I think the code to read in N-dep inside BLOM should be totally bypassed in this case. If you want to use the NDEP forcing that is different than what DATM is providing now in CDEPS - that should be a change to DATM.
• The way CTSM handles input ndep is via drv_flds_in (see lnd_import_export.F90 in its nuopc cap). It determines the number of ndep flds sent from the atmosphere component in drv_flds_in.

    ! from atm - nitrogen deposition
    call shr_ndep_readnl("drv_flds_in", ndep_nflds)
    if (ndep_nflds > 0) then
       call fldlist_add(fldsToLnd_num, fldsToLnd, Faxa_ndep, ungridded_lbound=1, ungridded_ubound=ndep_nflds)
       ! This sets a variable in clm_varctl
       ndep_from_cpl = .true.
    end if
        .....
 
    ! Atmosphere ndep
    if (fldchk(importState, Faxa_ndep)) then
       ! The mediator is sending ndep in units of kgN/m2/s - and ctsm
       ! uses units of gN/m2/sec so the following conversion needs to happen
       call state_getimport_2d(importState, Faxa_ndep, forc_ndep(begg:,:), rc=rc)
       if (ChkErr(rc,__LINE__,u_FILE_u)) return
       do g = begg, endg
          atm2lnd_inst%forc_ndep_grc(g) = (forc_ndep(g,1) + forc_ndep(g,2))*1000._r8
       end do
    end if

• If NDEP is received from the mediator when HAMOCC is defined then it will work for any ocean resolution.
• In CDEPS/DATM, there is an optional nitrogen deposition stream set by the xml variable DATM_NDEP it currently supports the following forcings (see $SRCROOT/cdeps/datm/cime_config/stream_definition_datm.xml)
  • presndep.clim_1850
  • presndep.clim_2000
  • presndep.clim_2010
  • presndep.hist
  • presndep.SSP1-2.6
  • presndep.SSP2-4.5
  • presndep.SSP3-7.0
  • presndep.SSP5-8.5
  • presndep.cplhist

I would be happy to give everyone a more detailed overview of how cdeps handles this and discuss how BLOM can leverage this capability.

@mvertens , many thanks for your detailed explanation - just to summarize, essentially, no reading of forcing files should be needed any longer inside iHAMOCC and instead should be streamed through BLOM via nuopc/CDEPS - either from CAM (interactively coupled) or DATM (input forcing field, e.g. in ocean only setups and non-interactively coupled NorESM setups). Currently, N-deposition is read and applied inside iHAMOCC. For this PR, it means that we may have to reconsider rather the mo_apply_ndep.F90 file and how N-deposition is applied there (due to summation for the current default iHAMOCC settings). For #397, it still means that summation, etc. needs to be carried out differently and new files need to be generated that can then be handled in the new way (due to the envisaged split of N species into NHx and NOy).

Reading your comment @mvertens , though, brought up (a maybe naive) general question in terms of design strategy:

• What is the benefit of doing all this through BLOM and not having a biogeochemistry cap that handles the flow of information between atmosphere and ocean biogeochemistry for tracers directly and thus more explicitly (while I see that e.g. wind speed is needed by both, BLOM and iHAMOCC to current stage)?

Further,

• I am not using it, but isn't there still the possibility to run a BLOM setup without using cime (@JorgSchwinger)? - how would it work then - or do we have to support the reading of input files (and prepare them for the different grids) inside iHAMOCC, while omitting their usage, once nuopc is used?
• @mvertens : do you want me to provide the files that you mentioned above (presndep.****), but with subdivision into the two N-species (NHx and NOy) that we will need moving forward?

@jmaerz - good questions.

1. What is the benefit of doing all this through BLOM and not having a biogeochemistry cap that handles the flow of information between atmosphere and ocean biogeochemistry for tracers directly and thus more explicitly (while I see that e.g. wind speed is needed by both, BLOM and iHAMOCC to current stage)?

• The coupling architecture for NorESM/CESM is a hub and spoke - components do not exchange information with each other - on information with a mediator (or coupler) that is responsible for regridding data from source to destination and merging data from multiple mapped sources to the target destination.
• You want to minimize the number of "components" that the mediator handles. We have an atm component and a ocean component - each one can have multiple physics/biogeochemistry options that can be activated and that require different fields to go through the mediator. It would be much less flexible to say suddenly that now there are now two 'atm' components - say chemistry and physics that exchange information with two blom components- say ihamocc and physics. You would need to generate new run sequences, new coupling data structures in the mediator, etc - and you really would not gain anything. So the NUOPC cap in each component decides what to send and receive based on the complexity that is configured for that component. Does that help?

2. I am not using it, but isn't there still the possibility to run a BLOM setup without using cime (@JorgSchwinger)? - how would it work then - or do we have to support the reading of input files (and prepare them for the different grids) inside iHAMOCC, while omitting their usage, once nuopc is used?

• If you use NORESM including CMEPS, CDEPS and BLOM - you are required to use the workflow/scripting of CIME. There is no other option with the NUOPC cap code. It is there to communication with the mediator. If you want to use stream functionality to ingest data outside of CIME - you could still do that but you need to figure out how to build the system with CDEPS - you can't do it without.

3. For Preparing N-deposition input files for CMIP6 scenarios and historical runs #397, it still means that summation, etc. needs to be carried out differently and new files need to be generated that can then be handled in the new way (due to the envisaged split of N species into NHx and NOy).

• Actually I believe that the current DATM forcing files have NHx and NOy split out -and CTSM sums up the contribution.
  As an example see /cluster/shared/noresm/inputdata/lnd/clm2/ndepdata/fndep_clm_WACCM6_CMIP6piControl001_y21-50avg_1850monthly_0.95x1.25_c180802.nc which is one of the ndep forcing files in DATM.

I'm happy to explain this in more detail on a call.

Dear @mvertens and @jmaerz

there might be a misunderstanding(?), please let me clarify: HAMMOC uses several fields as boundary conditions

• N-deposition
• Dust deposition
• Nutrient input through rivers

While all these fields can be coupled to an active atmosphere or land model, this will in the near future not be the default (also not for N-deposition). Therefore, by default, all these fields need to be read in by HAMOCC. Since this is also the case in coupled compsets, I don't think it would be practical to do this through DATM. Rather, as far as I have understood, this would be a typical use-case for the "inline" functions of CDEPS as it has been done for the SSS-relaxation in BLOM.

There are therefore two separate issues:

1. Can we replace the reading of pre-interpolated input data for dust, N-dep, and river nutrients by CDEPS inline function calls, which greatly alleviates the work of creating new grids

2. For N-deposition we need in addition the capability to receive the N-dep fields from an active atmosphere model for certain compsets.

There are modules mo_read_xxx and the reading of data is done in the BLOM-iHAMOCC interface. The xxx fields for the current timestep are then passed to the "core" HAMOCC (the call to hamocc4bcm) and mo_apply_xxx is used to actually do the dust- or N-deposition or river input. I would suggest to keep this structure, and add (later replace) the option to read the input data from CDEPS streams as done for SSS-relaxation inside mo_read_xxx, if that would be possible. For N-deposition the call to mo_read_ndep would be skipped if the atmosphere model provides the fields.

Dos this make sense? We might need a zoom call on this?

@JorgSchwinger - thanks for the clarifications. I think both 1. and 2. are straightforward to implement. I think a zoom call once I've finished implementing would be good to make sure we are all on the same page.